Computer-readable medium having a private key encryption program

ABSTRACT

A digital wallet stores an cryptographically camouflaged access-controlled datum, e.g., a private key encrypted under the user&#39;s PIN. Entry of the correct PIN will correctly decrypt the stored key. Entry of certain pseudo-valid PINs will also decrypt the stored key, but improperly so, resulting in a candidate key indistinguishable from the correct key. Such pseudo-valid PINs are spread thinly over the space of PINs, so that the user is unlikely to realize a pseudo-valid PIN via a typographical error in entering the correct PIN. In existing wallet technologies, which lack pseudo-valid PINs, only the correct PIN produces a decrypted key; thus, hackers can find the correct PIN by entering all possible PINs until a key is produced. The present invention&#39;s plurality of candidate keys prevent a hacker from knowing when he has found the correct key. In addition, hacker detection may be moved off-line into devices accepting messages signed with candidate keys, and/or the lockout threshold may be increased. Thus, the wallet can be forgiving of typographic or transposition errors, yet a hacker trying large numbers of PINs will eventually guess a pseudo-valid (but still incorrect) PIN and recover a candidate private key whose fraudulent use will be detected. The wallet may be used with associated key generation, certification, and verification technologies. Such technologies may include pseudo-public keys embedded in pseudo-public certificates, i.e., public keys that are not generally known and which are contained in certificates that are verifiable only by entities so authorized by the certifying authority.

FIELD OF THE INVENTION

[0001] The invention relates generally to cryptographically securing anaccess-controlled datum and, more specifically, to secure cryptographickey storage and use.

BACKGROUND OF THE INVENTION

[0002] Cryptographic data security techniques secure data by encryptingthe data with a key. The decrypted data can only be recovered using thekey. The key is selected to be sufficiently long that a maliciousintruder cannot guess the key by exhaustive trial and error, even withthe use of substantially large amounts of computing resources.Therefore, the security of the data has been transferred to the securityof the key. Often, it is desirable to store the key so that access tothe key is controlled by a pass-phrase or PIN (Personal IdentificationNumber) that is short enough for a human user to remember easily. Thiswould conveniently enable the human user to use his PIN to recover thekey, and then use the key to recover the encrypted data. Unfortunately,if the PIN is short enough for the human to remember, it is also shortenough for a malicious intruder to guess by exhaustive trial and error,thereby undermining the security of the key, and hence the security ofthe encrypted data. This has long been a vexing problem in datasecurity. In the present invention, we will offer a solution to thisproblem, using a fundamentally new technique called cryptographiccamouflaging. In contrast with conventional methods that aim to concealthe key, this new technique will camouflage the key by embedding it in amultitude of apparently similar keys. The keys are sufficientlydifferent that the legitimate owner of the data can locate the correctkey without any difficulty, using a short PIN that he can remember. Yet,the keys are sufficiently alike that a malicious intruder will find allof them equally plausible. The only way the intruder can select thecorrect key via trial and error, is to verify his trials with either theowner of the key, or with an administrative authority, thereby exposinghimself. While the discussion that we will present is in the exemplarycontext of storing private keys for digital signatures, those skilled inthe art will readily recognize that the technique of cryptographiccamouflage can be used to secure other forms of data.

[0003] We now return to our discussion of the background of theinvention. In asymmetric cryptographic methods such as RSA, each userholds a matched pair of keys, a private key and a public key. Theprivate key and the public key form a unique and matched pair in thatmessages (e.g., messages, data, code, and any other digitallyrepresentable information including other cryptographic keys orcryptographic representations of information) that are encrypted withthe private key can only be decrypted with the public key and viceversa. This one-to-one correspondence between the private key and thepublic key can be used to create digital signatures for electronicmessages and transactions. In order to sign an electronic message, a usecan simply encrypt the message with his private key. He would thenattach his public key to the encrypted message and send it to therecipient. Alternatively, the user would not attach his public key tothe message, but the recipient could look up the user's public key in adirectory of public keys. In either case, to verify the signature, therecipient would decrypt the message using the attached public key, andif the decryption is successful, the recipient is confident of theorigin of the message.

[0004] As described above, the sender would have to encrypt the entiremessage with his private key to sign it, which is computationallyexpensive. To address this, it suffices to compute a short hash of fixedlength, say 128 bits long, of the message and then encrypt the hashvalue. If the hash function is a good one, such as MD5, the chances oftwo distinct messages having the same hash value is extremely small.Therefore, digital signature methods typically compute hashes ofmessages, and encrypt only the hash value. The encrypted hash value andthe public key of the sender are attached to the original message priorto transmission to the recipient. To verify the signature, the recipientwould first compute the hash of the received message. If the computedhash value is the same as the decrypted form of the encrypted hash, therecipient is confident of the origin of the message.

[0005] In the foregoing, the strength of the signature verificationprocess depends on the recipient's confidence that the public keyattached to the message is indeed the public key of the purported owner.Anybody can generate a matched pair of keys can masquerade as the user,unless there exists a means to prevent such a masquerade. To this end,public keys are often certified by third-party notaries calledcertifying authorities or CAs for short. Examples of certifyingauthorities are commercial entities such as Verisign and Entrust. The CAbinds a certifiee's public key with the certifiee's identity, and thensigns the combined message with the CA's private key, to form thecertifiee's public key certificate. Thus, a certificate holder wouldattach his public key certificate to the encrypted message prior tosending the message to the recipient. To check the sender's identity andthe authenticity of his public key, the recipient verifies the CA'ssignature on the sender's public key certificate, using the CA's publickey. Since there would only be a small number of widely trusted CAs, theCA's public key would be reliably and easily available to the recipient.Thus, public key signatures can be used for stranger-to-strangerauthentication in that even if the recipient and the sender have noprior relationship, the recipient can verify the sender's signature aslong as the recipient and the sender both trust a common CA.

[0006] The uniqueness and unforgeability of a user's signature dependvery strongly on the ability of the user to keep his private keyprivate. Anybody who has access to the private key of a user canmasquerade as that user with complete anonymity. Hence, widespread useof digital signatures for electronic commerce and other applicationswill require technology for the secure storage of private keys. Atpresent, it is widely believed that private keys are best stored byphysically isolating them on hardware devices such as smart cards,Fortezza cards, PCMCIA cards and other compact hardware devices. Smartcards are credit-card sized cards that contain a microprocessor and somememory. The user's private key and public key certificate are writtenonto the memory. To use the card, the user would simply insert the cardinto an appropriate card reader connected to a host computer, and thenenter his PIN to activate the card. If the correct PIN is entered, theon-card processor would release the private key for use on the hostcomputer. If an incorrect PIN is entered, the processor would notrelease the user's private key. Some tamper-resistant smart cards areconfigured so that if incorrect PINs are entered on several consecutiveactivation attempts, the card locks up permanently. Some sophisticatedsmart cards (often called cryptocards) can perform cryptographicoperations, so that the private key need never leave the smart card. Thebytes to be processed enter the smart card from the host computer, areprocessed, and are then transmitted back to the host computer.Unfortunately, even cryptocards must rely on the host computer fortransmitting the bytes back and forth from the card reader and aretherefore not perfectly secure. A malicious host computer could simplysubstitute one message for another prior to transmission, so that theuser thinks he is signing one message, while in fact he is signinganother. Therefore, even cryptocards cannot combat malicious hostcomputers.

[0007] While the smart card solves the problem of securely storingprivate keys, it suffers from several significant drawbacks:

[0008] 1) High Initial Cost: Smart cards require expensive additionalhardware infrastructure in the form of smart card readers;

[0009] 2) Administrative Overhead: Smart cards require administrativeoverhead for distribution and upkeep; and

[0010] 3) Low User Convenience: The user cannot duplicate, backup orcollate smart cards, owing to their tamper proof features.

[0011] A secure software-based key wallet that does not requireadditional hardware would mitigate some of the drawbacks of the smartcard listed above. Unfortunately, there are no such solutions presentlyavailable. The standard technology that is used today for key storage,in products such as those of Microsoft and Netscape, offers very littleprotection against tampering, and can be broken into rather easily.Specifically, these key wallets store the private key in encrypted form,using the user's PIN as the encryption key. The PIN must be short enoughfor the user to remember, say a six-digit code. If such a software keywallet falls into the hands of a hacker, the hacker could exhaustivelytry all one million possible six-digit codes in an automated fashion ona personal computer within a few minutes, until he finds the code thatopens the key wallet. At this point, the hacker knows that he hasexactly the correct PIN, and has access to the user's private keys.Thus, the primary problem with providing a software-only key wallet arethe competing requirements that the PIN be short enough for the user toremember, but long enough to make the key wallet tamper resistant.

BRIEF DESCRIPTION OF THE FIGURES

[0012]FIG. 1 is a schematic overview of a cryptographic key wallet andkey generation, key certification, and verification subsystems.

[0013]FIG. 2 illustrates a conventional key wallet.

[0014]FIG. 3 illustrates an exemplary embodiment of a key walletaccording to the present invention.

[0015]FIG. 4 illustrates a distribution of pseudo-valid PINs among thespace of all possible PINs.

[0016]FIG. 5 illustrates a neighborhood surrounding a correct PIN.

[0017]FIG. 6 illustrates a known-plaintext attack that is addressed by asigning aspect of the present invention.

[0018]FIG. 7 illustrates an exemplary embodiment of a signing aspect ofthe present invention.

[0019]FIG. 8 illustrates an exemplary embodiment for generatingwell-formed private keys in a key generation aspect of the presentinvention.

[0020]FIG. 9 illustrates an exemplary system for digitally signing amessage, including a key wallet and associated key generation logic.

[0021]FIG. 10 illustrates a known public key attack that is addressed bya pseudo-public certificate aspect of the present invention.

[0022]FIG. 11 illustrates a conventional and an exemplary pseudo-publiccertificate.

[0023]FIG. 12 illustrates an exemplary certificate server aspect of thepresent invention.

SUMMARY OF THE INVENTION

[0024] The present invention offers a new technique for data storagecalled cryptographic camouflaging. In contrast with conventionalcryptographic methods that aim to conceal the data, the presentinvention camouflages the data by embedding it amongst many pieces ofsimilar data. The embedding is varied in that the pieces of data aresufficiently different that the legitimate owner of the data can locatethe correct piece without any difficulty, using a short PIN that he canremember. Yet, the embedding is homogenous, in that the pieces of dataare sufficiently alike that a malicious intruder will find all of themequally plausible. The only way the intruder can select the correct datavia trial and error is to verify his trials with either the owner of thedata, or with an administrative authority, thereby exposing himself.

[0025] Preferably, the multitude of data pieces selected for theembedding satisfy the competing constraints of being sufficiently variedfor the convenience of the legitimate owner, and yet sufficientlyhomogenous to foil the malicious intruder. Those skilled in the art willrealize that such an embedding may be tailored to the specific contextof each particular application. In this specification, we discuss anexemplary application of storing private keys in a key wallet,compatible with existing public key signature methods such as RSA, DSS,El-Gamal, elliptic curve cryptosystems, and their associated keygeneration, verification and certification technologies. Those skilledin the art will also realize that the technique of cryptographiccamouflaging can also be applied to other embodiments, by following thegeneral methods of the exemplary embodiment. Therefore, the term keywallet (or, alternatively, digital wallet) should be understoodgenerally to refer to any device for storing cryptographic camouflagedaccess-controlled datum rather than only the exemplary embodimentdescribed herein.

[0026] A key wallet may be implemented as a software wallet, which theuser would unlock, using a PIN, in much the same way as he would use asmart card. The advantages of a software-based wallet scheme include:

[0027] 1) Low Cost: The system does not require additional hardwareinfrastructure. The wallet can be embodied in any digital storage mediumincluding floppy disks, hard disks, magnetic stripe cards, and evensmart cards themselves;

[0028] 2) Low Administrative Overhead: The wallet can be distributedelectronically and updated electronically as required;

[0029] 3) High User Convenience: The user can duplicate, backup, andcollate wallets. Wallets can also be transmitted electronically;

[0030] 4) Tamper Resistance: The wallet can be tamper resistant infunctionally the same sense as a smart card; and

[0031] 5) No Undue Burden on User: The user's experience with the walletwould be the same as that with the smart card, and the user would notrequire unusually long PINs, or require extreme care in entering PINs,etc.

[0032] Other associated aspects of the present invention relate to thecreation and management of public-key certificates usable with the abovekey wallet. The advantages of such certificates include:

[0033] 1) Limited liability: The public key is pseudo-public, and itsuse is limited explicitly to authorized verifiers who are authorized bythe certifying authority. This could also, as a practical matter, limitthe legal liability of the certifying authority.

[0034] 2) Certificate Revocation: Public-key certificates may be createdthat are only useful to authorized verifiers; thus, revocation of thecertificates is facilitated to the extent that only the authorizedverifiers need to be notified of the cancellation of a certificate.

[0035] Of course, although there are many advantages to a software-onlyimplementation of the present invention, parts or all of the systemcould even be implemented in a combination of hardware and software, oreven purely in hardware, providing great flexibility for deployment andusage. We first describe a metaphor for the cryptographicallycamouflaged key wallet system, followed by a summary of a technologicalrealization thereof.

[0036] Consider the problem of selecting a lock for the main door of ahome. We could select a small, inexpensive lock with a key that is smallenough to be carried conveniently. Or we could select a large, stronglock, with a big key that is difficult to carry around conveniently. Athird alternative is a strong electronic lock with a key card, such asthose used in hotels and other institutions. Such electronic locks areexpensive and involve some administrative overhead, but they are bothconvenient and secure. Metaphorically speaking, the inexpensive locksrepresent the simple passwords that are widely used to protect computingresources; the strong locks with the big keys represent public keymethods—they are powerful but cumbersome; the electronic key card locksrepresent public key authentication methods with smart cards for storingthe keys. In this metaphor, the conventional software solution forprivate key storage is equivalent to hiding the key under the doormat.The user locates the key under the doormat using his PIN. Unfortunately,it is easy for the malicious hacker to exhaustively search under thedoormat until he finds the key. In contrast, using the presentinvention, the user could hide 10,000 keys under the doormat. One ofthese keys is the correct key and will unlock the door. The remainingkeys will either not work and/or set off alarms when used. The keys arecarefully specified to be sufficiently different so that the legitimateuser can find the correct key easily even in the dark. However, the keysare sufficiently alike that all of them look equally plausible to theintruder, and selection of one wrong key does not give useful feedbackas to a next key to try.

[0037] The key wallet aspect of the present invention is a technologicalrealization of the above metaphor of cryptographic camouflaging. In oneembodiment thereof, the key wallet stores the private key in encryptedform, where the encryption key is the user's PIN. The user recovers hisprivate key using his PIN, which is typically a six-digit code. If theuser enters exactly the correct PIN, he will recover his private keycorrectly. If the user enters an incorrect PIN, one of two things willhappen: (a) the key wallet will not open; or (b) the key wallet willopen and an incorrect private key will be recovered. For example, of the1,000,000 possible six-digit PIN codes, 10,000 of them will result inthe key wallet opening and yielding a candidate private key. However,only one of these candidate private keys will be the correct privatekey. The others will be incorrect keys that will nevertheless look justas plausible as the correct private key. As with the metaphor above, thelegitimate user will be able to locate the correct private key, since heknows the true PIN. The malicious hacker who exhaustively tries allpossible PINs will recover all 10,000 candidate private keys, all ofthem equally plausible. The only way the hacker can find out which ofthese keys is the correct one is to use the keys at some enterpriseauthorized to accept them. This would, with high likelihood, expose thehacker as an intruder. In the foregoing, the user of the key wallet is aperson accessing the private key contained therein. Alternatively, theuser need not be a person, but could be an application program, ahardware device, or some agent of a person. However, as a matter ofconvenience, the term user shall be used herein in the exemplary contextof a person accessing the key wallet.

[0038] The foregoing describes an exemplary implementation ofcryptographic camouflaging, directed at secure storage of private keysusing a PIN. Those skilled in the art will realize, however, that thepresent invention is usable generally for secure storage of anyaccess-controlled datum (ACD) using any digitally representable accesscode. Therefore, the term key wallet (or, alternatively, digital wallet)should be understood generally to refer to any device for storingcryptographic camouflaged access-controlled datum rather than only theexemplary embodiment described herein. Finally, still other relatedaspects of the invention include key generation, verification andcertification technologies, as will be explained in detail below.

[0039] Persons skilled in the art will recognize that applications ofthe present invention include, but are not limited to: (a) strongauthentication for secure remote/local access to computing and storageresources; (b) reduced user sign-on in environments with multiplecomputers on a network; (c) strong authentication for secure accessthrough firewalls with or without the IPSEC network protocol; (d)digital signatures for secure electronic commerce transactions; (e)digital signatures for electronic payment mechanisms; (f) secure accessto databases and/or digital signatures for database transactions; (g)secure access to routers and network switches; (h) secure access todistributed services; and (i) embedded applications wherein the user(e.g., of the digital wallet) is represented by a computational agent,such as a program running in software or hardware, as applied to, butnot limited to, any of the aforementioned applications.

DETAILED DESCRIPTION OF THE INVENTION

[0040]FIG. 1 gives a schematic overview of functional elements of theoverall system, each of which plays a role in the secure storage of theprivate key and its subsequent use. The first component is the keygeneration component 100, which creates the public and private keys forthe user. The second component is the key wallet 110, which stores theprivate key and is used to create signatures. The third component is theverification component 120, which is used to verify the signaturescreated by the key wallet. The fourth component is the certificationcomponent 130, which is used to certify the public key created by thekey generation component. The key wallet component provides theembedding for the cryptographic camouflaging, while the other elementsensure that the embedding is sufficiently varied to be of convenience tothe legitimate user, and yet appears sufficiently homogeneous to foilthe malicious intruder. In an exemplary embodiment of the invention, theforegoing are implemented as software running on a general purposecomputer.

[0041] 1. Details of the Key Wallet

[0042] For the purpose of analysis, we consider the key wallet to be asoftware-based lockbox containing the user's private key. Assume alsothat the lockbox can only be unlocked by a secret PIN that is known onlyto the legitimate user. Suppose the key wallet falls into the hands of amalicious hacker. We enumerate the kinds of attacks the hacker can mounton the black box, and provide a means to resist each attack. In theinterest of clarity, the discussion will be set forth with respect tothe RSA public key signature system. However, those skilled in the artwill appreciate that the basic elements of the discussion are applicableto other systems as well, including, without limitation, the El-Gamaland DSS signature systems, and elliptic curve cryptosystems.

[0043] a. PIN Hash Attack

[0044] A conventional key wallet is depicted schematically in FIG. 2. APIN 200 (more generally, an access code) entered to unlock the wallet ispassed through a one-to-one hash function 210. The hash function mayalso include a salt value or other security-enhancing feature, as willbe appreciated by persons skilled in the art. The hashed value 215 ofthe entered PIN is compared with a stored hash value 220, which is thehashed value of the correct PIN. If the two hash values agree, the PINis passed to decryption module 240. The private key which has beenencrypted (with the correct PIN as the encryption key) and stored infield 230, is decrypted by decryption module 240, which is typically DESor some other cryptographic function such as, for example, triple-DES,IDEA or BLOWFISH. Hence, the decrypted private key 250 is released foruse.

[0045] The cryptographic operations of computing the hash(es) anddecrypting the stored hash may be implemented using one or morecryptographic logic (e.g., software) modules, and the correct hash valueand private key may be stored in protected data fields or other forms ofmemory (e.g., read from ROM, from computer-readable media, etc.). Atypical key wallet would also include input and output logic forreceiving candidate PINs and outputting decrypted private keys, as wellas logic for management, viewing, copying, and handling of keys andother data.

[0046] The one-to-one nature of the hash function ensures that thecorrect PIN and only the correct PIN will unlock the key wallet.Unfortunately, it also provides the malicious hacker completeinformation to automate the process of guessing the correct PIN. In atypical implementation, the PIN is a code of six or fewer digits. Thehacker simply has to find the six-digit code that hashes to the storedhashed value. If he gets a copy of the key wallet, he can carry out thisattack on his computer, completely undetected and in an automatedfashion, in a matter of a few minutes. For example, he might write aprogram that simply checks all six-digit PIN codes on the key wallet.

[0047] To resist the PIN hash attack, the present invention replaces theone-to-one hash with a many-to-one hash, i.e., a hash in which manyinputs produce (i.e., regenerate) the same hashed output. This isdepicted in the flow chart of FIG. 3. In a typical implementation, themany-to-one hash function 310 might hash six-digit codes to two-digithash values. As in the conventional key wallet, the hashed value 315 ofthe entered PIN 300 is compared with the stored hash value 320, which isthe hashed value of the correct PIN. If the two hash values agree, thekey wallet opens. The private key is again stored encrypted in field 330of the key wallet, with the correct PIN as the encryption key. When thecorrect PIN is entered, the stored encrypted key is decrypted and thecorrect private key 350 is released for use. However, since the hashfunction is many-to-one, there will be many different entered PINs thatwill open the key wallet. (PINs that hash to the same hash value as thecorrect PIN, including the correct PIN, are called pseudo-valid PINs.)For example, if the hash function hashes six-digit codes to two-digithash values, there will be 10,000 six-digit pseudo-valid PINs that willopen the key wallet, out of a total of 1,000,000 possible six-digitcodes. Pseudo-valid PINs will all be passed to the decryption module 340to decrypt the stored encrypted key to produce a candidate private key.However, all but one of these candidate private keys will be incorrectdecryptions of the stored (correct) private key. Only when the enteredPIN is the correct PIN will the correct private key be recovered.

[0048] Preferably, the many-to-one hash function above should be chosento be a good hash. For example, and without limitation, MD5 and SHA arewell-known good hash functions. Good hash functions are one means tosubstantially uniformly distribute the pseudo-valid PINs in the space ofall possible PINs. For example, consider a hash function from six-digitcodes to two-digit hash values. Of the 1,000,000 possible input values,10,000 will be pseudo-valid PINs. If the hash function is a good hash,these values will be substantially uniformly distributed. In particular,one in a hundred PINs will be pseudo-valid, and these will beeffectively randomly distributed. Specifically, the chances are{fraction (1/100)}that if the user makes a typographical error inentering the correct PIN, then the resulting PIN will be a pseudo-validPIN. Pictorially, this is seen in FIG. 4, where the space of allpossible PINs is shown as a wall 400. The holes 410 in the wallcorrespond to the pseudo-valid PINs. Only one of these holes 420corresponds to the correct PIN, as shown in the figure. Notice thatthere is a neighborhood of PINs around each pseudo-valid PIN that willnot hash to the stored hash value. Compare this with FIG. 5, which showsthe space of PINs for a one-to-one hash as used in the conventional keywallet. Notice that FIG. 5 shows only one hole 510, corresponding to thecorrect PIN. Also notice that the local neighborhood of the correct PINin FIG. 4 looks like the neighborhood of the correct PIN of FIG. 5. Inthis sense, the legitimate user's experience with the key wallet of thepresent invention is very similar to his experience with theconventional key wallet.

[0049] Another possible scenario involves using a weak hash, i.e., onewhich results in clustering of pseudo-valid PINs, whereby an intruderwho guesses one pseudo-valid PIN will more easily find others. Alegitimate user making a series of 1-digit typographical errors wouldalso get a sequence of pseudo-valid PINs and, if the system acceptingthe private key or messages encrypted thereby has analarm-or-disable-upon-repeated-failure feature, this would inadvertentlylock out the legitimate user. Thus a weak hash is typically disfavoredover the good hash. Nevertheless, there may be some applications where aweak hash provides certain characteristics such as computationalefficiency and ease of implementation that are advantageous forspecialized applications.

[0050] b. Known Signature Attack

[0051] Another common attack is the known signature attack. In thisattack, sometimes called a known-plaintext attack, the malicious hackerhas access to two pieces of information: (a) the user's key wallet; and(b) a message (in both plain text and signed form) that was previouslysigned by the user. This attack is shown pictorially in FIG. 6. Thehacker will try all possible PINs 600 on the key wallet, and for eachpseudo-valid PIN, use the decrypted private key 610 to sign the knownplain text 620, creating a signature 630. If the signature 630 matchesthe known signature of the user 640 of the same plain text message, thehacker knows that he has discovered the correct PIN and has recoveredthe user's correctly decrypted private key. In the conventionalsignature process, the plain text message to be signed is hashed using ahashing algorithm (such as MD5), and the hashed plain text is encryptedusing the user's private key to form the signature. Often, apseudo-random pad is added to the plain text prior to hashing to resistchosen plaintext attack. Such pseudo-random bits are typically generatedfrom a seed that is stored on the key wallet, or some other source thatcan be traced and replicated, such as the time of day, etc. Adisadvantage of such pseudo-random bits is that an attacker whodetermines the randomness generation mechanism can obtain usefulfeedback for the known signature attack. Thus, an aspect of the presentinvention resists this attack via a variation on the signature process.

[0052] As shown in FIG. 7, the signing component of the presentinvention pads the hashed plain text 720 with strongly random bits 710,prior to encryption with the private key 730, to create anon-replicatable signature 740. Such strongly random bits may begenerated using a method that relies on a source of randomness outsidethe key wallet. Examples of such are physical sources of randomness,such as the variation in the seek time of the disk drive on a hostcomputer, the random time intervals between keystrokes on a keyboard, orrandom characters input by a user. These and other methods forgenerating strong randomness are well known to those skilled in the art(e.g., see D. Davis, R. Ihaka, and P. Fenstermacher, “CryptographicRandomness from Air Turbulence in Disk Drives,” Advances in Cryptology:Proc. Crypto 84, Springer-Verlag, 1985, pp. 183-215; or, more generally,Bruce Schneier, Applied Cryptography, 2nd Ed., Wiley, 1996). The purposeof such strong random pads is to ensure that signatures cannot bereplicated by a malicious hacker, since he does not know the random pad,and cannot recreate the random pad from any information stored in thekey wallet as might be the case with a pseudo-random pad. Still otherapplications of strong randomness to dissuade attacks are well known tothose skilled in the art, and can be implemented in alternativeembodiments of the present invention.

[0053] c. Ill-Formed Key Attack

[0054] Another attack is one in which the malicious hacker tries allpossible PINs and, for each pseudo-valid PIN, examines the decryptedkey. If the key is not well formed, the hacker knows that thepseudo-valid PIN cannot be the correct PIN. Therefore, it is necessaryto ensure that candidate private keys, derived by decrypting the storedkey with pseudo-valid PINs, are also well-formed.

[0055] In the RSA system, a private key has an exponent (d) and amodulus (n), and is said to be well-formed if the modulus does not haveany small factors and the exponent d is smaller than (p−1)(q−1) and notdivisible by p or q, where p and q are the prime factors of the modulusn. Therefore, the modulus and exponent of candidate private keys mustalso meet these conditions. One embodiment of the present invention thatensures both conditions is shown in FIG. 8. Assuming the correct privatekey was properly formed, the modulus 810 is stored unencrypted and isnot modified by the encryption/decryption process. Therefore, thecandidate private key's modulus is well formed by definition. Theproblem, then, is ensuring that the candidate private key's exponent(hereafter, the “candidate exponent”) is well-formed. The likelihood ofthe candidate exponent sharing prime factors with the modulus isextremely small, and comparable with the likelihood of factoring themodulus serendipitously. Therefore, the primary constraint is on thesize of the candidate exponent relative to the modulus. One way ofensuring this is as follows. Since the exponent of the correct privatekey (hereafter, the “correct exponent”) was well-formed, candidateexponents that are similar in size to the correct exponent are likely toalso be well-formed.

[0056] One method of ensuring this is to divide the correct exponentinto its most significant portion 820 and least significant portion 830.For example, 65537 has “65” as its most significant 2 digits and “537”as its least significant 3 digits. The most significant bits are storedunencrypted, while only the least significant bits of the correctexponent are encrypted using the PIN and stored. When the stored leastsignificant bits are decrypted using a pseudo-valid PIN, they willchange completely (e.g., 537 might become 142 in the example above). Thestored most significant portion and the decrypted form of the leastsignificant portion are then assembled to recover the candidate exponent840. However, the magnitude of the reassembled candidate exponent willnot have changed significantly. By properly choosing the number of leastsignificant bits, one can control the order of magnitude of therecomputed candidate exponent, to ensure that it remains smaller thanthe modulus. The foregoing illustrates the concept ofleast-significant-bit-encryption using base-10 arithmetic. Thecorresponding computer-based implementation would be similar, exceptusing bits rather than digits. For example, if the modulus has 512 ormore bits, an exemplary implementation might encrypt only the 128 leastsignificant bits of the exponent using the PIN as the key.

[0057] Those skilled in the art will realize that there are manyalternative ways of ensuring that candidate private keys arewell-formed. In an alternative method, the key generation module selectstwo random numbers k and m, where m is a number between d and themodulus n. In an exemplary implementation, k could be of length 64 bits.The sum d+km is computed, k is discarded, and m is stored for later use.Rather than storing the correct exponent d, the sum d+km is thenencrypted using the PIN, and stored as an encrypted sum. When apseudo-valid PIN is entered, the encrypted sum is decrypted to obtainthe decrypted sum, which is then evaluated modulo m. That is, acandidate exponent is recovered as the remainder after dividing thedecrypted sum d+km by m. Such a candidate exponent is, by construction,smaller than m. Since m was selected to be smaller than the modulus n,the candidate exponent is therefore also guaranteed to be smaller thann.

[0058] The foregoing illustrates two exemplary embodiments for ensuringwell-formedness of RSA-compatible candidate private keys. As thoseskilled in the art will appreciate, the concept of ensuringwell-formedness also extends to other private keys and, more generally,to other types of stored, access-controlled data. For example andwithout limitation, if the stored datum were a combination to a physicalsafe, the candidate datum would have to be in proper format for thecombination dial. Any access-controlled datum having an expected formatcan be stored using this aspect of the present invention in whichwell-formedness is ensured during decryption by candidate access codes.

[0059] d. Combination Attacks

[0060] To simultaneously resist the PIN hash attack, the known signatureattack and the ill-formed key attacks, the various aspects of thepresent invention as shown in FIG. 3, FIG. 7 and FIG. 8 can be combinedas shown in the assembly of FIG. 9. Persons skilled in the art willrecognize that any combination, subset or superset of the attacks can beresisted by combining (or modifying) the appropriate aspects of thepresent invention, for use in environments where that particularcombination, subset or superset of the attacks is of concern.

[0061] 2. Details of the Certification Component

[0062] The certification component of the present invention createspubic key certificates that are somewhat different from the conventionalpublic key certificates. Essentially, public keys as used herein are nottruly public as with conventional methods, but are meant for limiteddistribution (e.g., within organizations, across intranets or otherwisewithin closed or pseudo-public enterprises). This deviation fromconventional methods is used to resist the following attack on theprivate key.

[0063] a. Known Public Key Attack

[0064] In this attack, the malicious hacker has access to two pieces ofinformation: (a) the user's key wallet, and (b) the user's public key,as might be readily available in a public key certificate directory. Theattack is shown pictorially in FIG. 10. The hacker will try all possiblePINs 1000 on the key wallet, and for each pseudo-valid PIN, he would usethe decrypted private key 1010 to encrypt an arbitrarily chosen samplemessage 1020, and then decrypt the encrypted message with the user'spublic key. If the decrypted message 1040 matches the plain text samplemessage, the hacker knows that he has discovered the correct PIN andrecovered the user's correctly decrypted private key.

[0065] To resist this attack, one embodiment of the present inventiondoes not permit public keys to be truly public As a matter ofconvenience, we shall call such limited-distribution public keys“pseudo-public keys” and we shall call certificates containing suchpseudo-public keys “pseudo-public certificates.” Specifically,pseudo-public certificates contain the user's pseudo-public key inencrypted form. Only authorized parties can access a pseudo-public keyto verify the user's signature. This is in strong contrast with theconventional use of public key certificates, where anybody can verify apublic key signature. Of course, the key wallet and other aspects orembodiments of the present invention could be used with conventionalcertificates alone, but even greater security is provided ifpseudo-public keys and certification are also used, as described herein.Those skilled in the art will readily appreciate that existingcertification issuance devices and procedures may readily be adapted toaccommodate the foregoing embodiment of the present invention.Therefore, the specific hardware and/or software implementations of thisembodiment of a certification component need not be described in detail.Rather, only the differences from the conventional certificates will bedescribed below. Readers skilled in the art will recognize thatconventional certificates come in several formats, most notable of whichis the X.509 format and its revisions; however, the essential elementsof all the conventional formats are similar, when viewed in relation tothe present invention.

[0066] A conventional public key certificate and one possible embodimentof a pseudo-public certificate are shown side by side in FIG. 11. Theexemplary pseudo-public certificate may have the same format as theconventional certificate. However, the body of the certificate 1100containing the pseudo-public key is encrypted in a manner that isreadable only by an authorized verifier. For example, in oneimplementation, the encryption could be by the public key of theauthorized verifier. Only authentication servers that have access to thecorresponding private key can unwrap the user's certificate to accessthe user's public key. If there are several authorized verifiers, thebody of the certificate could carry several encrypted copies of thepseudo-public key, each copy being encrypted by the public key of one ofthe verifiers. Each enterprise or entity employing this aspect of thepresent invention would have a certificate server having theabove-described certification components to support its pseudo-publiccertificates. Persons skilled in the art will appreciate that theimportant characteristic of the pseudo-public certificate is that thepublic key is encrypted and can be decrypted only by authorizedverifiers, and this characteristic may be achieved in many differentways using a variety of cryptographic algorithms. For example, in analternate embodiment of the pseudo-public key certificate, the publickey would be encrypted by a DES key, and the DES key would be encryptedby the public key of the authorized verifier.

[0067] The resulting certificate would then be signed by the certifyingauthority similar to a conventional certificate. It is the pseudo-publicnature of public keys in the present invention that provides for twosignificant advantages in key management. Firstly, since the certifyingauthority is explicitly aware of who is authorized to use the public-keycertificates, the legal liability of the CA could, as a practicalmatter, be limited. This is in contrast to the conventional certificatewhere the CA has no prior knowledge of who will use the certificate.Secondly, revoking a public-key certificate is made easy, since the CAonly has to notify those verifiers authorized to use the public-keycertificates.

[0068] Certificates of the proposed form will be issued by thecertification component, acting as a certificate server as shown in FIG.12. As those skilled in the art will appreciate, the server willcomprise a series of logic modules that can be implemented in software,hardware, or a combination thereof. The user who wishes to be certifiedwill submit a digitally signed request for such as input 1210 to thecertificate server 1200. Such a request would typically contain theuser's public key that is to be certified, along with his name or otheridentifying attributes. The certificate server would verify the user'sdigital signature using the submitted public key. If the signatureverifies correctly, the server would check the user's identityinformation in the database 1220, and then issue a public keycertificate 1230 of the proposed form as output. Those skilled in theart will recognize that the user identity database could be supplantedby other sources of information to verify the identity of the userrequesting the certificate.

[0069] An alternate realization of the pseudo-public certificate servercould involve a modification unit to be attached to a conventionalcertificate server. Such an add-on unit could operate on the input orthe output of the conventional certificate server. In the event themodification unit operates on the input, it would repackage the requestfor the certificate by encrypting the users public key, and embed theencrypted public key among the identification attributes. Themodification unit would then attach a dummy public key to the request,sign the request with the associated private key and pass on the requestto the conventional certificate server. The output of the conventionalcertificate server would be a certificate containing the encryptedpublic key of the user as one of the identifying attributes. In theevent the modification unit operates on the output of a conventionalcertificate server, the unit would repackage the conventionalcertificate produced by the conventional certificate server byencrypting the public-key exponent in the certificate in situ, and thenoverwriting the signature of the certificate server with a freshsignature of the modified certificate. Persons skilled in the art willappreciate that other alternative embodiments are possible.

[0070] 3. Details of the Key Generation Component

[0071] This component generates the public and private key of a user atset-up time, when the user creates his credentials. Public key creation(whether in the conventional sense or in the pseudo-public sense) inthis aspect of the present invention is generally similar toconventional key generation techniques, but with a slight modificationto resist the following attack.

[0072] a. Known Public Key Exponent Attack

[0073] This is an attack that is particular to the RSA cryptosystem, andis a variant of the known public key attack described above. In the RSAsystem, it is common to use public keys with simple, fixed exponents(e.g., 3 or 65537) to accelerate cryptographic operations.Unfortunately, this makes it possible for the malicious hacker to mounta known public key attack. The hacker will try all possible PINs on thekey wallet, and for each pseudo-valid PIN, he would extract thedecrypted private key and separate it into the private exponent and themodulus. Since a RSA public key consists of the known exponent and thesame modulus, the hacker can combine the two to assemble a candidatepublic key. He would then mount the known public key attack describedabove. In order to resist this attack, the key generation aspect of thepresent invention can utilize public keys with long exponents, say64-128 bits, that are generated randomly at key generation time.

[0074] 4. Details of the Verification Component

[0075] The verification component of the present invention differs intwo ways from the verification component in conventional systems. Theverification component must respect the pseudo-public nature of thepublic key certificate, and take appropriate steps to extract a user'spublic key from the certificate before verifying the user's signature.In an exemplary embodiment of this aspect of the invention, these wouldinclude receiving a certificate containing an encrypted pseudo-publickey of the certificate holder, and using the private key of anauthorized verifier to decrypt the pseudo-public key. The verificationcomponent would then use the pseudo-public key to verify a digitalsignature in a message sent by the certificate holder. In an alternativeembodiment, if a DES key had been used to encrypt the pseudo-public key,the DES key would first be decrypted using the private key of theverfier, and in turn the DES key used to decrypt the pseudo-public key.No matter what the decryption mechanism, the verification componentshould also include logic to detect break-in attempts by fraudulenthackers, e.g., those signing messages with incorrect candidate privatekeys corresponding to the pseudo-valid access codes of the key walletaspect of the present invention. In such a case, a fraudulent hackermight steal or otherwise obtain the legitimate user's pseudo-publiccertificate and send the certificate along with a fraudulent messagesigned with the incorrect candidate private key. The inconsistencybetween the legitimate user's correct pseudo-public key in thecertificate and the incorrect candidate private key allows detection ofthe fraudulent user. In particular, in one embodiment, if a particularuser's signature is not verified in three successive attempts, theverification component concludes that a break-in might be in progress,and freezes the user's access privileges pending further investigation.In addition to (or instead of) freezing the access, the verificationcomponent might sound an alarm alerting an operator of the attemptedbreak-in. There are other methods of detecting break-in attempts at theverification component, and other possible courses of action upondetecting a break-in. As those skilled in the art will appreciate, theverification component will compromise a series of logic modules thatcan be implemented in software, hardware, or a combination thereof.

[0076] 5. Modifications, Enhancements and Alternate Embodiments

[0077] The foregoing has described various aspects of the presentinvention. Although in one preferred embodiment, the key wallet, the keygeneration component, the key verification component and the keycertification component are all used together to provide a securetechnology for cryptographic key storage and use, those skilled in theart will appreciate that in alternative embodiments, various subsets ofthe whole system may also be combined for particular applications notrequiring all of the components.

[0078] In addition, although all of the foregoing has been describedwith respect to a software-based system, this is not strictly necessary.For example, some or all of the components could be deployed usingmicrocode and PLAs or ROMs, general purpose programming language andgeneral purpose microprocessors, or ASICs. That is, the invention is notlimited to software per se, but could be deployed in virtually any formof logic, including pure software, a combination of software andhardware, or even hardware alone.

[0079] Furthermore, although various embodiments or aspects have beendescribed with regard to RSA cryptography (for the public and/orpseudo-public keys and public and/or pseudo-public certificates) or DEScryptography (for the PIN encryption and storage of the pseudo-publickey on the pseudo-public certificate), those skilled in the art willappreciate that many modifications and enhancements to such exemplarycryptographic technology are possible. More generally, each of theaforementioned operations can be implemented from a broad choice ofcryptographic techniques, including many kinds of asymmetric orsymmetric encryption as well as CRCs, hashes, message digests, or otherone-way functions. For example, an asymmetric encryption operation couldbe replaced with a (optionally keyed) one-way function where integrityis the primary concern, or encryption of a symmetric session keyfollowed by use of the session key for plaintext encryption, and variousother alternatives that are well-known to those skilled in the art.Finally, although the exemplary embodiment has been described withrespect to PINs protecting a private key, those skilled in the art willrealize that the same technology of cryptographic camouflaging can beused with other types of access codes and cryptographic representationsto protect any access-controlled datum. Therefore, it is intended thatthe scope of the invention be limited only by the claims appended below.

What is claimed is:
 1. An apparatus for managing access to acryptographically secured access-controlled datum, comprising: (a) inputlogic for receiving a candidate access code; (b) a first memoryconfigured to store a cryptographically camouflaged access-controlleddatum; (c) first cryptographic logic operatively connected to said inputlogic and said first memory for processing said cryptographicallycamouflaged access-controlled datum using said candidate access code;and (d) output logic for providing said processed datumaccess-controlled datum to a user of said apparatus.
 2. The apparatus ofclaim 1 wherein: (a) said access-controlled datum has been at leastpartially encrypted using an access code; (b) a second memory configuredto store a cryptographic representation of said access code; (c) saidfirst cryptographic logic includes: (i) second cryptographic logicoperatively connected to said input logic and configured to regeneratesaid cryptographic representation of said access code in response tosaid candidate access code belonging to a plurality of pseudo-validaccess codes; and (ii) third cryptographic logic configured to receivesaid regenerated cryptographic representation from said secondcryptographic logic, and operatively connected to said first memory andto said input logic for using said received candidate access code indecrypting said stored encrypted access-controlled datum to produce adecrypted access-controlled datum.
 3. The apparatus of claim 2 whereinsaid access-controlled datum is a cryptographic key.
 4. The apparatus ofclaim 3 wherein said cryptographic key is a private key.
 5. Theapparatus of claim 4 further comprising a pseudo-public keycorresponding to said private key.
 6. The apparatus of claim 5 furthercomprising a pseudo-public certificate containing said pseudo-publickey.
 7. The apparatus of claim 6 wherein said pseudo-public key isencrypted.
 8. The apparatus of claim 7 wherein said pseudo-public key isencrypted with a public key having a corresponding private key that isnot generally known.
 9. The apparatus of claim 4 wherein said privatekey is well-formed.
 10. The apparatus of claim 9 wherein said privatekey includes a modulus not having any small factors, and an exponentsmaller than said modulus.
 11. The apparatus of claim 9 wherein saidprivate key includes: (a) a cleartext representation of said modulus;and (b) a cryptographic representation of at least a part of an exponentcorresponding to said modulus.
 12. The apparatus of claim 11 : (a)further comprising a third memory for storing a number larger than saidexponent and smaller than said modulus; and (b) wherein said at leastpart of said exponent is stored in an expanded form which, whenevaluated modulo said number, equals said at least part of saidexponent.
 13. The apparatus of claim 11 wherein said at least part ofsaid exponent represents certain less significant bits of said exponent.14. The apparatus of claim 3 wherein said second cryptographic logic forsaid regeneration of said cryptographic representation of said accesscode includes a many-to-one hash.
 15. The apparatus of claim 14 whereinsaid many-to-one hash is a good hash.
 16. The apparatus of claim 2wherein: (a) said cryptographic representation includes a hash function;and (b) said second cryptographic logic for said regeneration of saidcryptographic representation includes a many-to-one hash.
 17. Theapparatus of claim 16 wherein said many-to-one hash is a good hash. 18.The apparatus of claim 17 wherein said good hash is characterized inthat said plurality of pseudo-valid access codes are distributedsubstantially uniformly among a plurality of invalid access codes. 19.The apparatus of claim 16 wherein said access-controlled datum is aprivate key.
 20. The apparatus of claim 19 further comprising apseudo-public key corresponding to said private key.
 21. The apparatusof claim 19 wherein said private key is well-formed.
 22. The apparatusof claim 19 further comprising digital signing logic including: (a)input logic for receiving a message to be signed; (b) randomizing logicfor generating random data; and (c) fourth cryptographic logicoperatively connected to said input logic and to said randomizing logicfor: (i) padding said received message with said generated random data;and (ii) signing said padded message with said decryptedaccess-controlled datum.
 23. The apparatus of claim 2 wherein said thirdcryptographic logic is configured to disallow said decryption when saidreceived candidate access code is an invalid access code.
 24. Theapparatus of claim 2 implemented as a software program.
 25. Theapparatus of claim 2 implemented as a hardware device.
 26. The apparatusof claim 2 further comprising digital signing logic including: (a) inputlogic for receiving a message to be signed; (b) randomizing logic forgenerating random data; and (c) fifth cryptographic logic operativelyconnected to said input logic and to said randomizing logic for: (i)padding said received message with said generated random data; and (ii)signing said padded message with said decrypted access-controlled datum.27. The apparatus of claim 26 wherein said generated random data isstrongly random.
 28. The apparatus of claim 27 wherein said generatedrandom data originates from a physical source.
 29. The apparatus ofclaim 2 wherein said third cryptographic logic for decrypting includes asymmetric cryptographic function.
 30. The apparatus of claim 29 whereinsaid symmetric cryptographic function is DES.
 31. The apparatus of claim1 wherein said stored access-controlled datum is a private key having acorresponding public key that includes a long exponent.
 32. Acryptographic key wallet comprising: (a) input logic for receiving auser-inputted access code that may belong to a plurality of pseudo-validaccess codes; (b) cryptographic logic for decrypting a storedaccess-controlled datum, using said pseudo-valid access code, uponcryptographically verifying said pseudo-valid access code; and (c)output logic for providing said decrypted access-controlled datum tosaid user.
 33. The cryptographic key wallet of claim 32 wherein saidaccess-controlled datum includes a private key having a correspondingpseudo-public key.
 34. The cryptographic key wallet of claim 33 furthercomprising a pseudo-public certificate containing said pseudo-publickey.
 35. A digital certificate server comprising: (a) input logic forreceiving from a requestor a digitally signed request for apseudo-public digital certificate, said request including: (i) apseudo-public key to be certified, and (ii) an identifying attribute ofsaid requestor; (b) cryptographic logic for verifying said digitallysigned request using said pseudo-public key; (c) logic for creating saidpseudo-public certificate upon said verifying said digitally signedrequest, said certificate including a cryptographic representation ofsaid pseudo-public key; and (d) output logic for providing saidpseudo-public certificate for said requester.
 36. The digitalcertificate server of claim 35 configured for use with a digital wallet,said digital wallet comprising: (a) input logic for receiving acandidate access code; (b) a first memory configured to store acryptographically camouflaged access-controlled datum; (c) firstcryptographic logic operatively connected to said input logic and saidfirst memory for processing said cryptographically camouflagedaccess-controlled datum using said candidate access code; and (d) outputlogic for providing said processed datum access-controlled datum to auser of said apparatus.
 37. The digital certificate server of claim 35wherein said pseudo-public certificate is of a modified conventionalformat.
 38. The digital certificate server of claim 35 wherein saidpseudo-public key is encrypted.
 39. The digital certificate server ofclaim 38 wherein said pseudo-public key is encrypted with a public keyhaving a corresponding private key that is not generally known.
 40. Thedigital certificate server of claim 35 implemented as an add-on modulefor use with a conventional digital certificate server.
 41. Apparatusfor verifying a digitally-signed message, comprising: (a) input logicfor receiving a digitally-signed message and a pseudo-public keyallegedly corresponding to a signer of said message; (b) cryptographiclogic for using a public key of an enterprise certifying authority tocryptographically verify the pseudo-public key; and (c) signalling logicfor detecting fraudulent use of said message upon failure of saidverified pseudo-public key to successfully verify said signed message.42. The apparatus of claim 41 wherein said digitally-signed message issigned using a candidate private key that was generated by acryptographic key wallet in response to a pseudo-valid access code. 43.The apparatus of claim 42 wherein said key wallet includes: (a) inputlogic for receiving a candidate access code; (b) a first memoryconfigured to store a cryptographically camouflaged access-controlleddatum; (c) first cryptographic logic operatively connected to said inputlogic and said first memory for processing said cryptographicallycamouflaged access-controlled datum using said candidate access code;and (d) output logic for providing said processed datumaccess-controlled datum to a user of said apparatus.
 44. The apparatusof claim 41 wherein said logic for detecting said fraudulent useincludes logic for freezing access to said apparatus upon a plurality ofunsuccessful attempted verifications.
 45. The apparatus of claim 41wherein said logic for detecting said fraudulent use includes logic foreffecting an alarm upon unsuccessful attempted verification.
 46. Theapparatus of claim 41 wherein said cryptographic logic for using apublic key of an enterprise certifying authority to verify thepseudo-public key includes cryptographic logic for decrypting saidpseudo-public key.
 47. The apparatus of claim 41 wherein said receivedpseudo-public key is contained in a pseudo-public certificate.
 48. Amethod for providing a stored cryptographically-securedaccess-controlled datum, comprising the steps of: (a) receiving acandidate access code from a user of a digital wallet; (b) accessing astored, cryptographically camoflagued access-controlled datum; (c)cryptographically processing said cryptographically camoflaguedaccess-controlled datum using said candidate access code; and (d)providing said processed datum access-controlled datum to said user ofsaid wallet.
 49. The method of claim 48 wherein said step ofcryptographically processing said cryptographically camoflagedaccess-controlled datum using said candidate access code includes: (a)accessing from a first memory within a digital wallet, anaccess-controlled datum that has been at least partially encrypted usingan access code; (b) accessing from a second memory within said digitalwallet, a cryptographic representation of said access code; (c)regenerating said cryptographic representation of said access code inresponse to said candidate access code belonging to a plurality ofpseudo-valid access codes; and (d) using said received candidate accesscode, decrypting said encrypted access-controlled datum to produce adecrypted access-controlled datum.
 50. The method of claim 49 whereinsaid access-controlled datum is a cryptographic key.
 51. The method ofclaim 50 wherein said cryptographic key is a private key.
 52. The methodof claim 51 wherein said private key is a member of a cryptographic keypair including a pseudo-public key corresponding to said private key.53. The method of claim 52 wherein said digital wallet includes apseudo-public certificate containing said pseudo-public key.
 54. Themethod of claim 53 wherein said pseudo-public key is encrypted.
 55. Themethod of claim 54 wherein said pseudo-public key is encrypted with apublic key having a corresponding private key that is not generallyknown.
 56. The method of claim 52 wherein said private key iswell-formed.
 57. The method of claim 56 wherein said private keyincludes a modulus not having any small factors, and an exponent smallerthan said modulus.
 58. The method of claim 56 wherein said private keyincludes: (a) a cleartext representation of said modulus; and (b) acryptographic representation of at least a part of an exponentcorresponding to said modulus.
 59. The method of claim 58 wherein: (a)said private key is stored in said first memory as an expanded form ofat least part of said exponent; and (b) said step of decrypting saidencrypted access-controlled datum includes: (i) retrieving from a thirdmemory a number larger than said exponent and smaller than said modulus;(ii) retrieving said expanded form of at least part of said exponentfrom said first memory; and (iii) evaluating said expanded form of atleast part of said exponent, modulo said number, to recover said atleast part of said exponent.
 60. The method of claim 58 wherein said atleast part of said exponent represents certain less significant bits ofsaid exponent.
 61. The method of claim 51 wherein said step ofregenerating said cryptographic representation of said access codeincludes performing a many-to-one hash.
 62. The method of claim 61wherein said many-to-one hash is a good hash.
 63. The method of claim 50wherein: (a) said cryptographic representation includes a hash function;and (b) said step of regenerating said cryptographic representation ofsaid access code includes performing a many-to-one hash.
 64. The methodof claim 63 wherein said many-to-one hash is a good hash.
 65. The methodof claim 64 wherein said good hash is characterized in that saidplurality of pseudo-valid access codes are distributed substantiallyuniformly among a plurality of invalid access codes.
 66. The method ofclaim 63 wherein said access-controlled datum is a private key.
 67. Themethod of claim 66 wherein said private key is a member of acryptographic key pair including a pseudo-public key corresponding tosaid private key.
 68. The method of claim 66 wherein said private key iswell-formed.
 69. The method of claim 66 further comprising the steps of:(a) receiving a message to be signed; (b) generating random data; (c)padding said received message with said generated random data; and (d)signing said padded message with said decrypted access-controlled datum.70. The method of claim 50 wherein said step of decrypting saidaccess-controlled datum is disallowed when said received candidateaccess code is an invalid access code.
 71. The method of claim 50implemented as a software program.
 72. The method of claim 50implemented via a hardware device.
 73. The method of claim 50 furthercomprising the steps of: (a) receiving a message to be signed; (b)generating random data; (c) padding said received message with saidgenerated random data; and (d) signing said padded message with saiddecrypted access-controlled datum.
 74. The method of claim 73 whereinsaid generated random data is strongly random.
 75. The method of claim74 wherein said generated random data originates from a physical source.76. The method of claim 50 wherein said step of decrypting saidencrypted access-controlled datum includes performing a symmetriccryptographic operation thereon.
 77. The method of claim 76 wherein saidsymmetric cryptographic operation is DES.
 78. The method of claim 50wherein said stored access-controlled datum is a private key having acorresponding public key that includes a long exponent.
 79. A method forproviding a stored cryptographically-secured access-controlled datum,comprising the steps of: (a) receiving, at a digital wallet, auser-inputted access code that may belong to a plurality of pseudo-validaccess codes; (b) decrypting, at said digital wallet, a storedaccess-controlled datum, using said pseudo-valid access code, uponcryptographically verifying said pseudo-valid access code; and (c)providing said decrypted access-controlled datum to said user of saiddigital wallet.
 80. The method of claim 79 wherein saidaccess-controlled datum includes a private key having a correspondingpseudo-public key.
 81. The method of claim 80 wherein said digitalwallet includes a pseudo-public certificate containing saidpseudo-public key.
 82. A method for generating a pseudo-public digitalcertificate comprising the steps of: (a) receiving from a requester adigitally signed request for a pseudo-public digital certificate, saidrequest including: (i) a pseudo-public key to be certified, and (ii) anidentifying attribute of said requester; (b) cryptographically verifyingsaid digitally signed request using said pseudo-public key; (c) creatingsaid pseudo-public certificate upon said verifying said digitally signedrequest, said certificate including a cryptographic representation ofsaid pseudo-public key; and (d) outputting said pseudo-publiccertificate for said requestor.
 83. The method of claim 82 furthercomprising the step of placing said created digital certificate in adigital wallet, said digital wallet comprising: (a) input logic forreceiving a candidate access code; (b) a first memory configured tostore a cryptographically camouflaged access-controlled datum; (c) firstcryptographic logic operatively connected to said input logic and saidfirst memory for processing said cryptographically camouflagedaccess-controlled datum using said candidate access code; and (d) outputlogic for providing said processed datum access-controlled datum to auser of said apparatus.
 84. The method of claim 82 wherein saidpseudo-public certificate is of a modified conventional format.
 85. Theapparatus of claim 84 wherein said pseudo-public key is encrypted. 86.The method of claim 85 wherein: (a) said pseudo-public key is encryptedwith a public key having a corresponding private key that is notgenerally known.
 87. The method of claim 82 performed via an add-onmodule for use with a conventional digital certificate server.
 88. Amethod for verifying a digitally-signed message, comprising the stepsof: (a) receiving, at a message verification apparatus, adigitally-signed message and a pseudo-public key allegedly correspondingto a signer of said message; (b) using a public key of an enterprisecertifying authority to cryptographically verify the pseudo-public key;and (c) detecting fraudulent use of said message upon failure of saidverified pseudo-public key to successfully verify said signed message.89. The method of claim 88 wherein said digitally-signed message issigned using a candidate private key that was generated by acryptographic key wallet in response to a pseudo-valid access code. 90.The method of claim 89 wherein said key wallet includes: (a) input logicfor receiving a candidate access code; (b) a first memory configured tostore a cryptographically camouflaged access-controlled datum; (c) firstcryptographic logic operatively connected to said input logic and saidfirst memory for processing said cryptographically camouflagedaccess-controlled datum using said candidate access code; and (d) outputlogic for providing said processed datum access-controlled datum to auser of said apparatus.
 91. The method of claim 88 wherein said step ofdetecting said fraudulent use includes freezing access to said messageverification apparatus upon a plurality of unsuccessful attemptedverifications.
 92. The method of claim 88 wherein said step of detectingsaid fraudulent use includes effecting an alarm upon unsuccessfulattempted verification.
 93. The method of claim 88 wherein said step ofusing a public key of an enterprise certifying authority tocryptographically verify the pseudo-public key includes decrypting saidpseudo-public key.
 94. The apparatus of claim 88 wherein said receivedpseudo-public key is contained in a pseudo-public certificate.
 95. Amethod for storing a stored cryptographically-secured access-controlleddatum, comprising the steps of: (a) receiving an access-controlleddatum; (b) cryptographically camoflaguing said access-controlled datumsuch to be recognizable by an authorized user thereof but unrecognizableto an unauthorized user thereof; and (c) storing said camoflagedaccess-controlled datum in a digital wallet.
 96. The method of claim 95wherein said step of cryptographically camoflaguing saidaccess-controlled datum includes: (a) receiving an access code; (b)computing a cryptographic representation of said access code, saidrepresentation having the property of being reproducible in response toa plurality of pseudo-valid access codes; (c) storing said computedcryptographic representation of said access code; (d) at least partiallyencrypting said access-controlled datum using said access code; (e)storing said at least partially encrypted access-controlled datum forsubsequent access by a user providing one of said plurality of saidpseudo-valid access codes.
 97. The method of claim 96 wherein saidaccess-controlled datum is a cryptographic key.